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Abstract 

The well known snapshot primitive in concurrent programming allows for n-asynchronous 
processes to write values to an array of single-writer registers and, for each process, to take a 
snapshot of these registers. In this paper we provide a formulation of the well known lineariz- 
ability condition for snapshot algorithms in terms of the existence of certain mathematical 
functions. In addition, we identify a simplifying property of snapshot implementations we 
call “schedule-based algorithms”. This property is natural to assume in the sense that as far 
as we know, every published snapshot algorithm is schedule-based. Based on this, we prove 
that when dealing with schedule-based algorithms, it suffices to consider only a small class 
of very simple executions to prove or disprove correctness in terms of linearizability. We 
believe that the ideas developed in this paper may help to design automatic verification of 
snapshot algorithms. Since verifying linearizability was recently proved to be EXPSPACE- 
complete, focusing on unique objects (snapshot in our case) can potentially lead to designing 
restricted, but feasible verification methods. 


1 Introduction 

The snapshot object was introduced by Afek et al. [HE], independently by Anderson [3] and 
by Aspens and Herlihy [Sj. The snapshot object is shared by n processes, po, ■ ■ ■ ,Pn-i- This 
object is divided into n segments when the Tth segment is “owned” by process p*. Each process 
Pi can write values to its segment by invoking an update(u) operation with an argument v taken 
from some fixed set of values Vais. In addition, each process can scan the entire array by 
invoking a scan operation. Thus, scan returns a vector consisting of n elements from Vais. The 
snapshot object is an efficient tool for achieving synchronization between n processes in the 
shared memory model (see chapter 9 in [8] for exact definitions), since it allows the processes 
to scan the entire shared memor}(l] at an atomic action. Therefore, it is not surprising that the 
snapshot object is so well-studied, especially due to the fact that it can be implemented using 
only single-writer registers. 

In [I],|3j and [5], while introducing the snapshot object, the correctness criterion adopted 
by the authors is the Linearizability criterion m which is, nowadays the standard correctness 
condition for implementation of concurrent objects. Informally, Linearizability is the require¬ 
ment that in any execution, each procedure execution can be identified with a unique moment 
during its actual execution, such that this identification yields a correct sequential execution 
(according to the specification of the object). The importance of this criterion is that it ensures 
an execution appears to a user as if it is sequential. This stands in contrast to other correctness 

^In this model it is suffice to assume that each process use only one single-writer register. 
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conditions. For example, this property does not hold if only sequential consistency [TB] is re¬ 
quired. As linearizability and sequential consistency are the main correctness criteria accepted 
by researchers (see [7] for detailed discussion), it is natural that the Linearizability criterion is 
widely adopted, as many authors claim [i3],[iij,[i5], m, m- 

The Linearizability criterion successfully formulates what one would consider as “good be¬ 
havior” of a concurrent system. Due to the complex nature of distributed systems, the research 
in the field of linearizability is deep and complicated. We see three aspects concerning this issue 

1. Implementing concurrent objects is hard. One can use the trivial solution and lock the 
system before every operation. However, it seems that avoiding such trivial solutions is 
solely at the hand of experts and researchers. 

2. Proving correctness of linearizable implementations is difficult. Examining known-results 
in literature reveals that in many occasions, proofs tend to be long and technical. More¬ 
over, many times proofs include clever and sophisticated ideas, so finding a correct imple¬ 
mentation is sometimes only half of the work required of the programmer. 

3. Automatic verification of linearizability is a hard problem. In general, it is undecidable 
HB, and if the number of processes is fixed and all methods are finite, the problem is 
EXSPSPACE-complete [B]. 

This paper includes three contributions. In theorem 13.21 we provide a necessary and suffi¬ 
cient condition for linearizability of executions of snapshot implementations. In definition 12.21 
we introduce the notion of schedule-based snapshot algorithm. This notion captures a natural 
property of concurrent implementations and in fact, we are not familiar with any published 
snapshot implementation which is not scheduled-based. Finally, in what we consider as our 
main contribution, we prove in theorem 14.21 that a schedule-based snapshot algorithm is correct 
if all its simple executions are correct. A simple execution is an execution in which all pro¬ 
cesses, excluding two processes, invoke only update(O) and scan operations. The remaining two 
processes may also execute an update(l) procedures, but once a process executes an update(l) 
procedure, it is not allowed to invoke an update(O) procedure again for the rest of the execution. 

Informally, a snapshot algorithm is scheduled-based if at any execution, the values that a 
scan operation returns depend on the interleaving of the actions performed by the processes, 
and not on the actual values that the update procedures wrote to the segments of the snapshot 
object. To illustrate the idea behind this notion, consider an execution in which, whenever a 
process executes an update procedure, it invokes update(m) when m is a counter that counts 
the number of update operations executed by the process. Now assume a different execution 
in which the processes take steps at the same order, but instead of calling update(m), the m- 
th update operation of each process is update(m -|- 1). In this case, we expect that if a scan 
operation at the first execution returns {ki,... ,kn), then there is a scan operation at the second 
execution, that occurred at the “same time” and returned {ki -t- 1,..., -|- 1). This is a natural 

property to assume, since the snapshot object deals with synchronization between reads and 
writes, and the actual values that the processes write to the segments are immaterial. It can be 
observed that authors refer to their algorithms as schedule-based without formulating exactly 
the scheduled-based notion. When Attiya, Herlihy and Rachman [6] write: 

we can ignore the real values written to the segments and refer only to the sequence 
numberqj that are written there. 

^These sequence numbers counts the number of update operations. 
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they mean that their algorithm is scheduled based. We understand their statement in the 
following manner: since the values returned by scan operations depend on the interleaving of 
the execution, but not on the actual values written to the segments, it suffice to assume that 
each process counts the number of update operations, and write the value of this counter into 
its segment. 

We do not claim that any snapshot algorithm is schedule-based and in fact, it is not dif¬ 
ficult to transform a correct schedule-based implementation into a correct not-schedule-based 
algorithm. But since (for the best of our knowledge) every published snapshot implementations 
is scheduled-based, in practice, a non-schedule-based algorithm is likely to be an algorithm 
obtained by optimization of some schedule-based implementation. 

We mentioned three difficulties concerning Linearizability: constructing correct implemen¬ 
tations is hard, proving correctness is difficult, and the problem is EXPSPACE-complete. We 
demonstrate now how our contributions address these three issues. 

1. A necessary and sufficient condition for correctness of executions of snapshot 
implementation. Our condition provides an alternative framework for designing correct 
snapshot implementation and for proving correctness of snapshot implementations. In¬ 
stead of trying to achieve linearizability, one needs to try to satisfy our condition. Possibly, 
some programmers will find our condition easier to work with. 

During the writing process of this paper, we were surprised to find out that our condition 
is similar to the condition in Anderson’s “shrinking lemma” [1]. However, we believe 
that our condition is more natural and it provides a better framework for programmers 
than the shrinking lemma. Our condition deals with the existence of functions between 
scan events and update events that satisfy some properties. Informally, for each i < n, 
we have a function ctj such that if S' is a scan event, ai{S) is the p^-update event in 
which Pi wrote to its segment the value read by S. It is clear that these functions must 
satisfy some properties. Eor example, there cannot be a pj-update event between ai{S) 
and S. In a similar way, our properties classify all the “bugs” that might occur in an 
execution. Thus, while proving correctness, it is reasonable that the programmer will be 
able define the functions uq, ..., On-i- She just need to explain which update events wrote 
the values returned by a scan event. To summary, we provide the programmer with a list 
of properties, and She needs to check that these bugs never arise in any execution, while 
writing the code or while proving correctness. 

2. Scheduled-based algorithms. Recently, verifying Linearizability was proved to be 
EXPSPACE-complete [16]. Thus, complete verification is infeasible. One way to overcome 
this gap is to check for errors in short executions |12j.[2n|.[24j. Another way is to ask the 
user to specify the linearization points [in],[22|. A remarkable result can be found in [23j . 
The key idea in [23| is to assume that the linearization points of the algorithm satisfy some 
properties. Since the general case is EXPSPACE-complete, it is necessary to adapt such 
assumptions, although the assumption in |23| excludes some known implementations, such 
as the queue implementation in HZ]. Here we suggest the schedule-based property. We 
see potential in this natural assumption, and it could lead to results concerning automatic 
verification of algorithms with reasonable time-complexity. 

We also suggest to look at specific objects. The general case might be difficult, but it 
is possible that for some specific objects, verification can be feasible. In this paper we 
focus on the snapshot object, but it is straightforward to generalize our notion for other 
objects as well, as long as the values returned by operations depend on the ordering of 
method invocations and not on the exact arguments (for example: stack, queue, etc. in 
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contrast to test-and-set). Thus, the ideas we develop in this paper may lead to similar 
results regarding other objects and data-structures, and may lead to improved verification 
techniques. 

3. Reduction to simple executions. Alur et al. [3] showed that linearizability is decidable 
when the number of processes is hxed and the implementation is finite (no unbounded 
registers are used such as integers, etc.). Regarding the snapshot object, it is possible that 
an implementation is infinite only because Vais is an infinite set. The traditional way 
to overcome this issue, is to check correctness under the assumption that the processes 
invoke only scan, update(O) or update(l) operations. In theorem 14.31 we prove that this 
assumption is suffice for schedule-based implementations. Therefore, we conclude that if 
SMAV is a schedule-based snapshot algorithm, and if only finitely many configurations of 
SNAV are reachable if the processes execute operations from {scan, update(O), update(l)}, 
then it is decidable to determine if SMAV is correct. This hold although the verification 
approach in [3] cannot be applied on sMAV directly. Moreover, our reduction to simple 
executions also reduces the running time of the verification procedure in [3] (in compare 
to the traditional approach mentioned above). Furthermore, our reduction shows that 
under some natural assumptions it suffice to consider only a small and simple class of 
executions. We believe that there is high potential in this reduction for obtaining a 
polynomial verification method of schedule-based snapshot algorithms. 

In addition, when one tries to develop a snapshot implementation, naturally, his construc¬ 
tion is likely to result in a schedule-based implementation. Thus, since we prove that 
is suffice to look at simple executions, we provide another framework for programmers. 
Instead of concerning that every execution is linearizable, one needs to consider only sim¬ 
ple executions of the implementations. Therefore, our result can help designing correct 
implementations and can ease the process of writing proofs. 


2 Preliminaries 

2.1 Executions of Snapshot Algorithms 

A snapshot algorithm SMAV is an implementation of two methods: update and scan, update 
gets as argument a value from a known hxed set of values, Vais, and scan returns a vector 
of n values from the set Vais, where n is the number of processes. Formally, each method is 
modeled as a transition system, and a process is a transition system that nondeterministically 
executes scan and update(n) operations with argument n G n. More precisely, from the initial 
state of process pi (which is a transition system) there are arrows for each operation scan or 
update(f), and each last action in a method ends in the initial state of pi. For a hxed number 
of processes n, we identify an algorithm SMAV with the parallel composition of the processes 
i.e. SMAV = PoIIpiII • • • Ibn-i (see chapter 2 in [9]). 

An execution r of SMAV is a hnite sequence of actions (named execution fragment in [9] ) that 
the processes execute according to the code of the algorithm SMAV. In an execution r, some of 
the methods invocations return and some are not. We say that an operation is complete, if the 
process that executed the operation has executed all the commands and returned. Otherwise, 
the operation is said to be pending. For a process pi, each action by pi is also named an action 
or a low level event, and each operation also named a high level event (see m for further 
discussion). When the context is clear, we use the term event without specifying if it is a low 
level or a high level event. Formally, a complete p^-event in an execution r is a pair {s,t) G N x N 
such that 
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1. s < t. 


2. t(s) is the first action by pi of an operation. 

3. r(t) is the last action by pi of an operation. 

4. For each s < I < t, t{1) is not a first action of an operation by pi. 

Since pending operations have no last action, we define a pending event to be a pair (s,oo), 
s E N so that; 

1. t(s) is the first action by pi of an operation. 

2. For each s < /, if t[1) is defined, then it is not a first action of an operation by pi. 

A high level event is either a scan event or an update event. For a high level event E, we also 
write that E is a, pj-scan event or a pj-update event for denoting which process executed the 
operation E. 

For an execution r, complete{T) denotes the set of all complete high level events in r, and 
events^r) is the set of all high level events in r, pending and complete. Clearly, complete^r) C 
events^r). In addition, if E is an update event we use valr{E) to denote the argument with 
which E has been invoked, and if Fi is a complete scan event, valr{E) is the n-elements vector 
that E returns. In addition, if Fi is a complete scan event we use valr-.i{E) to denote the element 
at the i-th entry of valr{E). In case that r is clear from the context, we use val{E) and vali{E) 
instead of valriE) and valr-i{E). 

The low level events in an execution r are linearly ordered by the precedence relation, <. 
We naturally extend this relation to high level events. For two high level events Ei = (si,ti) 
and E 2 = (S 2 T 2 ) we write Ei < E 2 if ti < S 2 , and we say in this case that Ei precedes E 2 and 
that E 2 follows El. Note that no high level event follows a pending operation. Although < is a 
linear ordering over the set of low level events, in many cases, < is only a partial ordering over 
the set of high level events since it is possible that for two high level events Ei and E2, neither 
El < E 2 or E 2 < Fii. Such high level events are said to be concurrent. < also relates low level 
events with high level events as follows: if Fi = (s, t) is an high level event and e = r(/) a low 
level event, we write e < E if I < s and E < e is t < 1. Furthermore, if s < / < t and both E 
and e are p^-events for a process pi, then we write e E Fi. 

For the purpose of our discussion, for simplicity, we assume that in any execution r each 
process executes an initial update operation in which the process writes the initial values to the 
registers (or just perform an initialization, when the exact form of the initialization depends on 
the communication media). Thus, we assume that in each execution r there are n initial update 
events that precede any other high level event. These update events are not necessarily follow 
the code of the algorithm, but they are considered as high level events in any execution. 

2.2 Linearizability 

Linearizability is the standard correctness condition for implementations of concurrent objects 
m Roughly speaking, an execution is linearizable if each operation can be seen as if it was 
executed in a unique instantaneous moment (the linearization point of the operation), during 
its actual execution. The requirement is that the identification of the high level events with 
their linearization points, yields a sequential execution that satisfies the correctness condition 
of the object: the sequential specification. 
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In an execution r, some operations are complete and some are pending. Some of the pending 
operations has affected the system and some may be neglected. Thus, the linearizability condi¬ 
tion described above relates to all the complete operations in addition to some of the pending 
operations. 

Now we describe the requirement formally. Let r be an execution of a snapshot algorithm 
SAfAV, and let < be the precedence relation defined over events{T). r is linearizable if there is 
a set of events 

complete{T) CSC events{T) 

and a linear ordering ^ on £" that extends <, so that the linear ordering {S,~<) satisfies the 
sequential specification of the snapshot object, presented below in figure [T] 


1. The procedure executions are partitioned into update(u) and scan operations, 
and are totally ordered by n initial update(u) operations are assumed, each 
initial update(u) operation has been executed by a different process. These 
operations precede all other operations in 

2. For a scan event S, let Ui denote the maximal update operation executed by 
Pi such that Ui ^ S thus val{S) = {val{Uo),... ,val{Un-i))- 

Figure 1: The snapshot sequential specification. 

Therefore, an execution r of a snapshot algorithm SMAV is said to be correct if it is lineariz- 
able, and a snapshot algorithm SAfAV is correct if all of its executions are correct. 

2.3 Schedule-Based Algorithms 

In section 4 we show that for a snapshot algorithm SAfAV, if SMAV is scheduled-based, then 
SMAV is correct iff all its simple executions are correct. Roughly speaking, an algorithm is 
scheduled-based if at any of its executions, the values that the (complete) scan operations 
return are a matter of scheduling and they do not depend on the actual values with which the 
update operations have been invoked. As an example, we consider an execution of a snapshot 
algorithm, illustrated in Figure [2j 


Ui =update(x) S =scan (x,y) 

Po ■ I- 1 I- 1 


. U2 =update(y) ^ Ujj =update(2:) 


Figure 2: first execution 

In this execution po executes an update(x) operation f7i, and then executes a scan operation 
S', which returns {x,y). In addition, pi executes an update(y) operation, U 2 , and then an 
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update(2;) operation, U 3 . As the scan operation, S, returns {x,y) we have 

val{S) = {val{Ui),val{U 2 ))- (1) 

The schedule-based property assumes that equation [T] holds due to the schedule of the 
execution and the operations that the process execute, but not on the values that the update 
operations are invoked with (namely, x,y and z). For example, if we let the processes operate 
in the same order as in the execution presented in Figure [2] and to execute the same operations 
only with different arguments, we shall get a similar execution as presented in the Figure El 


Po ■ 


Ui =update(o) S =scan (a, 6) 


U2 =update( 6 ) 
Pi ■ ^^ 


[ 


U3 =update(c) 


H 


Figure 3: second execution 

As the executions in hgures [2] and [3] are similar, we expect that equation [1] will hold in both, 
or in none of this two executions. Of course, this is just a unique example and formally, we 
require that for any two similar executions and for any scan event, any equation that resemble 
equation [1] will hold in both of the executions or in none. For providing the exact definition, we 
first formulate what we precisely mean when by saying that two executions are similar. 

Definition 2.1. Two execution r and t' are similar if 

1. Both are of the same length. 

2. For each I, t{1) and t'{1) are actions by the same process. 

3. For each process pi, the l-th pi-operation in t is a scan event iff the l-th pi-operation in t' 
is a scan event. 

Thus, in similar executions the processes operate at the same order and they execute the 
same procedures. Similar executions only differ by the values that the update operations are 
invoked with (and by the values that scan operations return, due to the difference in the values 
with which update were invoked). The property we want to formulate is that in similar execu¬ 
tions, the operations that correspond to each other start and end at the same time, and that 
the scan operations return the value wrote by corresponding update events. As an example, 
in Figure [2] the first pi-scan operation returns the values of the hrst po-update operation and 
the first pi-update operation. As the execution in Figure [3] is similar to this execution, the 
operations invoked and return at the “same time”, and the scan event also returns the values 
of the first update operations. 

Definition 2.2. A snapshot algorithm SAfAV is said to be a schedule-based algorithm (or just 
sb-algorithm) if for any execution t, there are functions af,..., 

a[ : complete scan events —^-pj-update events 
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such that for any execution t' similar to t: 

1. (s, t) G N X (N U {oo}) is a pi-scan (^updatej event in r ijf it is a pj-scan (^updatej event in 
t'. 

2. For complete scan event E 

valri{E) = {valr'{aQ{E)),... ,valT-i{afi-i{E))). 

Note that if r and t' are similar and E = {s,t), then by the first reqnirement E is a, scan 
event in r iff it is a scan event in t' . Moreover, for each i < n cxJ(E) is a pj-update event in 
both the executions r and t' thus valr'{aJ{E)) is well defined. 

Of course, not every snapshot algorithm is an sb-algorithm and in fact, it is possible to 
transform a correct snapshot algorithm into a correct algorithm which is not schedule based. 
However, as the snapshot problem deals with synchronization between processes, by the essence 
of the problem the schedule based property is very natural to assume. Indeed, we are not 
familiar with any published snapshot algorithm which is not schedule based and by the reasons 
described here, it seems unnatural to come up with such an algorithm. 

2.4 Finite Implementations 

Alur, et al. proved in [3] that it is decidable to determine if an implementation is linearizable 
with respect to a sequential specification, in case that number of processes is fixed and that all 
methods can be modeled as finite transition systems. As a consequence, since we do not make 
assumptions on the size of the set Vais (it can be inhnite), Alur et al. approach [] cannot be 
applied on snapshot implementations, (unless we assume that Vais is finite and then it can be 
applied on finite implementations.) 

We observe that some snapshot implementations are infinite only because Vais is infinite 
set. As an example, consider the classical snapshot algorithms in [2j. The algorithm in section 
3 is clearly infinite since each process use a field named seq which counts the number of update 
events. Now, the algorithm in section 4 is also infinite since each register rj store a value 
data € Vais and possibly \Vals\ = oo. But, in the second case, if all update events are invoked 
with values taken from some finite range, the registers may store only finitely many different 
values and we get a finite algorithm. 

For the purpose of our discussion, we say that a snapshot implementation is finite, if it is 
finite in case that the processes execute only scan,update( 0 ) and update(l) operations. Coming 
back to our example, the algorithm in section 3 in [2] is infinite while the one in section 4 is finite. 
According to theorem 14.31 it suffice to focus on simple executions, regarding sb-algorithms. We 
conclude that linearizability of finite snapshot sb-algorithms is decidable. 

3 A necessary and sufficient condition for the correctness of a 
snapshot algorithm 

In this section we present a necessary and sufficient condition for the correctness of an execution 
r of a snapshot algorithm SMAV. Here SMAV is not assumed to be an sb-algorithm. The condi¬ 
tion we describe is equivalent to linearizability of any execution of any snapshot implementation 
SNAV. Our condition relies upon the existence of n function oq, ..., On-ij 

ai : scan events —)■ pi-update events 

that satisfy several properties. In the next definition we define the properties that the functions 
are required to satisfy. 


Definition 3.1. Let {ctj : i G n} he a set of n functions such that 


ai : scan events —^ pj-update events. 

We say that the functions oq, ..., On-i are correct if the following properties hold 

property 1. For any eomplete scan event S and i < n, S returns val{ai{S)) at the i-th entry (i.e. 
vali{S) = val{ai{S))). 

property 2. For any complete scan event S and i < n, ->{S < 0,(5)). 

property 3. For any scan event S and any i < n, there is no p^-update event U so that ai{S) < U < S. 

property 4- For any two complete scan events, Si and S 2 , and for any i < n, if Si < S 2 , then 
ai{Si) < ai{S2). 

property 5. For any eomplete scan event S and for any i,j < n, there is no pj-update event U so that 
ai{S) <U < aj{S). 

property 6. For two complete scan events, Si and S 2 , we define: Si <a S 2 if^i < n{ai{Si) < ai{S 2 )). 
We require that for any two eomplete scan events Si and S 2 , <« ^2) A {S 2 <a 

We show that the properties definition 13.11 provide a necessary and sufficient condition for 
the correctness of an execution r. 

Theorem 3.2. r is eorrect iff there are n correct functions uq,. .. ,an-i, where 

Ui ; scan events —>■ pj-update events. 


Before we provide a formal proof for this proposition, we explain the idea behind theorem 
13.21 and the properties of definition 13.11 If r is an execution of a snapshot algorithm SNAV, we 
want to check if < (defines on the high level events) can be extended into a total order ^ that 
satisfies the sequential specification. The idea is to relate for each scan event S and a process 
Pi, some pj-update event Ui that will be the maximal pj-update that precedes S in This idea 
defines a function 

ai : scan events —)■ p^-update events 

by setting afiS) = Ui. We shall prove that if these functions uq, ..., satisfy the properties 
of definition 13.11 (namely, they are correct), then we can extend < into a linear ordering ^ so 
that: 

1. for each scan event S and i < n, ai{S) is the maximal pj-update event that precedes S 
in 

2. ^ satisfies the sequential specification (note that this easily stems from the previous claim 
and from property 1 in definition 13.ip . 

Now we turn to prove theorem 13.21 The easy direction of our proposition is the “only if’ 
direction, namely that if r is a correct execution, then there are n correct functions ao, ..., an-i, 


ai : scan events — )-pj-update events. 


Roughly speaking, for proving this direction we show that the negation of each property in 
definition [Q indicates a “bug” in the execution that prevents Linearizability. 
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We fix a correct execution r, a set 


complete{T) C £ C events{T) 

and we assume that {£, -<) is a linearization of r (i.e. ^ extends < on £" and satisfies the 
sequential specification). For any complete scan event S and i < n, we define ai{S) to be 
the maximal pj-update event that precedes S in We claim that these functions satisfy the 
properties of dehnition 13.11 As an example, we shall prove that property 6 hold, and we leave 
the straightforward proof of the other properties to the reader. 

Proof. Let Si and S 2 be two complete scan events. For proving that property 6 hold, assume 
for a contradiction that Si <„ S 2 and S 2 <a Si. Thus, for some i,j < n, ai{Si) < ai{S 2 ) and 
Oij{S 2 ) < aj{Si). Assume w.l.o.g. that Si ^ S 2 . As ^ extends <, we get 

ctj{S2) P aj{Si). 

Furthermore, by definition of aj we have 


By combining these two observations we conclude 

ctjiS2) -< C(j{Si) Si ^ S 2 

in contradiction to the dehnition of aj, namely that aj{S 2 ) is the maximal pj-update event that 
precedes 52 in □ 

For proving the second direction of theorem 13.21 we hx an execution r and we argue that if 
ctO) ■ ■ ■) Oin-i are correct functions, then r is correct. We dehne 

£ = complete{T) U {update events}. 

Clearly, complete{T) C T C events{T) and our strategy is to use the functions ao) ■ ■ ■ 
to construct a linear ordering -< on the set of events T, that extends <. Our proof relies on the 
idea mentioned earlier, namely that ^ is correct if for any complete scan event S and i < n, 
the maximal pj-update event that precedes [/ in is a*(S'). Hence, for a scan event S and 
a pi-update event U, we should linearize U before S if C/ < ai{S), and we should set S ^ U 
otherwise. However, it is not clear why this approach yields a linear or even a partial ordering. 
In order to overcome this problem we prove that by extending < in the way described above, 
we get an acyclic relation (and hence, this relation can be extended to a linear ordering). For 
the rest of the proof, we speak only about events in £, the reader may observe that all the scan 
events in £ are complete thus all the scan events we deal with from this point, are complete. 

Definition 3.3. For a scan event S and a p^-update event U, we define U < S if U < afiS) 
and S <\U otherwise. 

As we have said, we shall prove that there are no cycles in < U <]. First, we prove this fact 
only for <]. 

Lemma 3.4. If Xi < 1 X 2 < X^ < X 4 , then Xi <3 X 4 . 

Proof. There are two possible cases 
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Case 1. Xi is a scan event. We note that if X dY then one of the events X,Y is a scan event and 
the other is an update event. Thus, if Xi is a scan event, then our sequence is of the form 

Si <]UidS2d U 2 

where Si and S 2 are scan events, Ui is a pj-update event for some i < n and U 2 is a 
j?j-update event for some j < n. Since Si <\ Ui, by definition of <], Q!i(5i) < Ui. Since 
Ui < S 2 , we get Ui < ai{S 2 )- Therefore, 

ai(5i) <Ui< ai{S2). 

As a result ai(S'i) < ai{S 2 ) thus 

<« 52. 

Now, S 2 <1 U 2 indicates that aj{S 2 ) < U 2 - Since Si <„ S 2 , by property 6 , -'(S 2 <« Si) 
and hence aj(Si) < aj{S 2 )- Therefore, aj{Si) < U 2 either, and hence Si <lU 2 as required. 

Case 2. Xi is p^-update event for some i < n. Thus, our sequence is of the form 

17i <1 Si <1 U 2 d S 2 

where Ui is a pj-update event. Si and S 2 are scan events and U 2 is a pj-update event for 
some j d n. 

Si d U 2 d S 2 proves that aj(Si) d U 2 < aj{Si). Hence aj(Si) < aj{S 2 ) and Si da S 2 
holds. By property 6 , -'(S 2 <« Si) thus aj(Si) < aj(S 2 ). Ui d Si indicates that Ui < 
Q!j(Si). Therefore, from ai(Si) < ai{S 2 ) we get that Ui < ai{S 2 ) as well, and hence 
Ui d S 2 holds as required. 

□ 

A cycle of length m > 1 in a binary relation R is a sequence of elements (Ai,... ,Xm) so 
that (Aj, Aj+i) € R for each 0 d i d m and Ai = A^. 

Lemma 3.5. There are no cycles in d. 

Proof. Assume for a contradiction that there are cycles in <l and consider a cycle of minimal 
length (Ai,..., A^,) where m > 1. Since m is minimal, by lemma [33] we conclude that m < 5. 
If m is an even integer, then Ai is a scan event and Xm is an update event, or Ai is an update 
event and A^ is a scan event. Thus, if m is even then Ai ^ A^- The corollary is that 2 < m < 4 
and m is odd thus m = 3. Therefore, we get 

Ai <1 A 2 <1 A 3 and Ai = A 3 . 

Now, Ai can be a scan event or an update event. First, assume that Ai is a scan event. 
Thus, our cycle is of the form 

SdU dS 

where S is a scan event and U is a p^-update event for some i d n. SdU implies that (S) < U 
while U d S indicates the opposite. Thus, a contradiction has been reached. 

It is left to consider the case that Ai is apj-update event for some i d n. Thus, the sequence 
is of the form 

UdSdU 

where 17 is a pj-update event and S is a scan event. From U d S we conclude that U < ai{S), 
and from S' <1 17 we conclude the opposite. Thus, as in the previous case. This case leads to a 
contradiction as well. □ 
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So far, we have proved that there are no cycles in <3. For proving the same for < U <1 we 
need few more lemmas. 

Lemma 3.6. If X <\Y then ^{Y < X) 

Proof. There are two possible cases 

Case 1. y is a scan event. Thus, X is a pj-update event for some i < n and X < ai{Y). By 
property 2, -i{Y < ai{Y)) and hence T < X is impossible. 

Case 2. T is a pj-update event for some i < n. Thus, X is a scan event and ai{X) < Y. If we 
assume that Y < X we get ai{X) < Y < X in contradiction to property 3, and hence 

-(y<x). 


□ 


Lemma 3.7. If X <\Y <\ Z, then ->{Z < X) 

Proof. As before, X is either a scan event or an update event. 

Case 1 . A is a scan event. Thus, T is a pj-update event for some i < n and Z is a scan event. By 
definition of <], ai(X) < Y < ai(Z) and hence 

ai(X) < ai(Z). 

The assumption Z < X contradicts property 4 thus ^{Z < X). 

Case 2. A is a p^-update event for some i < n. In this case A is a scan event and Z is a pj-update 
event for some j < n. By definition of < 1 , A < ai(Y) and ctj(Y) < Z. Assume for a 
contradiction that Z < X. So, we get aj{Y) < Z < X < a*(A) and in particular 

aj{Y) <Z<ai{Y). 

Since Z is apj-update event, our conclusion contradicts property 5, and hence -■(Z < A) 
as required. 


□ 


Lemma 3.8. //Ai <] X 2 <1 ■ ■ ■ <1 Xm, then —i{Xm < Ai). 

Proof. Consider a sequence of the form Ai < X 2 <1 • • • <1 Xm- If m = 1, then the lemma clearly 
holds since -■(Ai < Ai). In addition, if m > 2 by several invocation of lemma ITTI (possibly 
none) we can construct a sequence Ai <3 • • • <l A^ so that 

• = n. 

• aTjtj — 

• 0 < A; < 4 . 

if A; = 1 we are done by the previous argument, and if k G {2,3}, by lemmas (3.61 and f3.7l we 
conclude that -'(A^ < Ai) and the lemma follows. □ 

Now we can prove that < U <1 can be extended into linear ordering. 

Lemma 3.9. There are no cycles in < U<]. 
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Proof. Assume for a contradiction that there are cycles in < U <1 and consider a cycle (Ai,..., Xm) 
of minimal length. Since < and <1 are both irreflexive, m > 2. According to lemma 13.51 for 
some i < m Xi < Aj+i so we may assume w.l.o.g. that Xi < X 2 . Since m is assumed to be 
minimal, by the transitivity of <, necessarily X 2 < A 3 . We consider two possible cases: 

Case 1. Ai < X 2 <- ■ ■<Xm = Ai. By lemma [3^ -if A^ < X 2 ) and hence for some e G A 2 , e' G A^, 
e < e'. So, since Ai < A 2 and e G A 2 we get Ai < e < e' G Ai. We have concluded that 
for some e' G Ai, Ai < e' and this is of course, a contradiction. 

Case 2. Ai < A 2 <] • • • <1 A^ < A^+i where A: + 1 < m. By lemma (3^ for some e G A 2 , e' G A^, 
e < e'. Thus, Ai < e < e' < A^+i and we get that Ai < A^+i, in contradiction to the 
minimality of m. 

□ 

As there are no cycles in < U <3, we conclude that < U <1 can be extended into a total 
ordering Indeed, we define <* to be the transitive closure of < UO. Since < U <1 is an 
acyclic relation, <* is a partial ordering and hence can be extended into a total ordering 

For completing the proof of theorem 13.21 we argue that if ^ is a linear extension of < UO, 
then ^ satisfies the sequential specification of the snapshot object (Figured]). Since < U <1 can 
be extended into a linear ordering, theorem 13.21 stems from the next lemma. 

Lemma 3.10. If P is a linear extension o/< U<l, then -< satisfy the sequential .specification. 

Proof. Let 5 be a scan event, we need to prove that S returns {val{Uo ),..., val{Un-i)) where Ui 

is the maximalpi-update event that precedes S in By property 1, S returns {val{aQ{S )),..., val{an-i{S))) 

thus it suffice to prove that for each i < n, ai{S) = Ui. 

By definition of < 1 , ai{S) O S and since ^ extends < 1 , ai{S) -< S. Thus, 

a* (5) ^ U. 

If [/ is a pj-update event so that ai{S) < U, then S <\U and therefore, S <U. So, since Ui -< S, 
ai{S) < Ui is impossible. However, Ui and ai{S) are both pj-events, and hence comparable in 
< thus Ui < ai{S). As ^ extends <, we have Ui ^ ai{S). As a result, 

a^{S) = Ui 

follows as required. □ 

We proved that an execution r of a snapshot algorithm SXAV is correct iff there are correct 
functions ao,..., a^-i so that 


ai : scan events — ^pj-update events. 

Of course, a snapshot algorithm is correct iff for every execution we can find correct functions 
as defined in definition KT\ In the next section we prove that when we deal with sb-algorithm 
it suffice to consider only a small class of executions to ensure the correctness of the algorithm. 

4 Simple Executions 

In this section we prove that if SMAV is an sb algorithm, then it is suffice to consider only some 
of the executions of SMAV in order to prove/disprove linearizability. 

The notion of an sb-algorithm is defined in section 2. For an sb-algorithm SMAV we define 
a set of executions, named simple executions. In these executions, the update procedures are 
invoked with only two different values thus w.l.o.g. we use 0 and 1 to denote these values. 
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Definition 4.1. Let r be an execution. We say that r is {i, j)-simple for two different integers 
i,j < n, if there are ri,rj G N such that the following hold. 

1. Let U he the r-th jjj-update event. If r < rt, then U is an update(O) operation and if 
r > ri, then U is an update(l) operation. 

2. In the same way, let U be the r-th pj-update event. If r < rj, then U is an update(O) 
operation and if r > rj, then U is an update(l) operation. 

3. AH other update procedure executions are invoked with the value 0. i.e. if k ^ i,j and U 
is apfc-update event, then U is an update(O) event. 

An execution r is simple if it is {i, j)-simple for some different integers i,j < n. 

Thus, in simple executions all processes, excluding two of the processes, invoke only update(O) 
and scan procedures. The remaining two processes at first execute update(O) and scan opera¬ 
tions, and at some point each process stops executing update(O) operations and starts executing 
update(l) operations. We claim that in order to prove the correctness of SWAV, it suffice to 
prove that any simple execution is correct. This can be deduced from the following proposition: 

Proposition 4.2. Let SMAV he an sb algorithm. If there is an incorrect execution r of SMAV, 
then there is a simple incorrect execution t' of SWAV. 

Proof. We fix an incorrect execution r and we shall prove that there is an incorrect simple 
execution t', which is similar (according to definition 1 2. ID to r. Recall that r admits n functions 

Oq ) • • • ) CKfi—l) 

aj : complete scan events —> pi update events 
that satisfy the properties of definition 12.21 In particular, for each complete scan event S, 

Valr{S) = {valr{aQ{S)), . . . , Valr{cPn-l{S))) ■ 

As r is incorrect, the functions af ,..., are incorrect and hence one of properties 2-6 of defi- 
nition lTTl is violated (note that property 1 holds by the definition of the functions aj,..., 

The construction of the simple execution t' is according to the property that fails to hold. We 
consider two cases: the case that property 2 fails and the case that property 6 fails. The cases 
in which one of properties 3-5 fails to hold are dealt similarly, and the construction of t' in 
these cases is left to the reader. Before we continue we remind that if r and t' are similar and 
= (s, t) G N X (N U {oo}) a high level event in r, then it is also a high level event in t'. 
Furthermore, if is a scan (update) operation in r, then it is also a scan (update) event in t'. 

Case 1. Property 2 does not hold. Thus, for some iff ^ n and a complete p^-scan event S, 
S < aJ{S), where aJ{S) is the /-th pj-update event. Write U = aJ{S), choose a process 
i.d. j i and consider the (i,j)-simple execution r' defined by: 

- ri = I, rj = 0 . 

— t' is similar to r. 

As t' and r are similar, S and U are scan and update events in t' and by definition, 
valr’-.i{S) = valr'{U). Moreover, as t' is (i,j)-simple with r* = I, 

valr'ffS) = valT-i{U) = 1 . 
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It is left to prove that t' is incorrect. Take n-functions ao, , a„_i 


Oi : scan events —^-pj-update events 


and we shall prove that ao,..., a^-i are incorrect. Since ao,..., are arbitrary, the 
conclusion is that t' is incorrect. 

If ?7 < a*(5), then S < U < a*(5) and property 2 is violated. However, if ai{S) < U, 
then valr/{ai{S)) = 0 and then property 1 fails to hold as valr':i{S) = 1. Thus, in any 
case the functions are incorrect and hence t' is an incorrect simple execution as required. 

Case 2. Property 6 does not hold. Therefore, there are some complete scan events 81,82 and 
i,j < n so that 



Assume that is the ti-th pj-update event and that aj( 52 ) is the t 2 -th p^-update 

event. Write Ii = a[(5i), I 2 = a[(S' 2 ), Ji = a'j{ 8 i) and J 2 = aj( 52 ). 

Let t' be an (i,j)-simple execution so that 

— t' is similar to r. 

- ri = ti + l, rj = t2 + l. 

As t' and r are similar, note that Ii,l2 are p^-update events in r', Ji, J 2 are pj-update 
events in t', and 81, 82 are complete scan events in rh Furthermore, since t' and r are 


similar and since t' is (i,j)-simple with ri = ti + 1 , rj = t 2 + 1 the following hold in t': 

1 . Ii < I2, J2 < Ji- 

2. valr':i{8i) = ua/:^(/i) = 0, valri-.j{8i) = = 1. 

3. valr':i{ 82 ) = val'.,.{l2) = 1, valr':j{ 82 ) = ua/^(J2) = 0. 

As in the previous case, let ao,..., On-i be n functions 


ctj : scan events —^-pj-update events 


and we need to verify that these functions are incorrect. If property 1 fails to hold we are 
done, and otherwise we have 

1 . valT-i{ai{8i)) = 0 , valri{aj{8i)) = 1 . 

2 . valr'{ai{ 82 )) = 1 , valr'{aj{ 82 )) = 0 . 

Since Ii is the last pj-update event invoked with the value 0 we conclude 


< h < ai{ 82 ). 


( 2 ) 


Similarly, since J 2 is the last pj-update event invoked with the value 0 we conclude 


aj{ 82 ) < J 2 < aj{ 8 i). 


( 3 ) 


Equations [5] and [3] imply that 


ai( 5 i) < Q!i( 52 ) A aj{ 82 ) < aj{ 8 i) 


thus in this case, property 6 fails to hold. 
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□ 


By proposition 14.21 we conclude. 

Theorem 4.3. A snapshot algorithm SMAV is correct iff all the simple executions of SNAV are 
correct. 

Now, let SMAV be finite sb-snapshot algorithm. By our corollary, in order to check the 
correctness of SMAV it suffice to check only executions in which the update events are invoked 
with the values 0 or 1. Recall that under this restriction only finite states of SMAV are reachable 
as SMAV is assumed to be finite. In [3] Alur et al. proved that linearizability is decidable for 
algorithms with finite states and a fixed number of processes. Thus, based on Alur et al. result 
we have 

Corollary 4.4. It is decidable to determine if a finite sb-snapshot algorithm is correct. 

5 Conclusions 

In section 3 we defined a necessary and sufficient condition for correctness of executions of 
snapshot algorithms. Our condition relays upon the existence of functions ao,... jCtn-i be¬ 
tween scan event and update events by po,... ,Pn-i respectively. A programmer is likely to be 
able to define these functions for hers implementation. Our condition provides programmers 
with a framework for implementing snapshot algorithms and proving correctness of snapshot 
algorithms. 

We have defined the schedule-based notion. Here, we focus only on snapshot implemen¬ 
tations but the schedule-based notion can be applied on other objects as well, such as stack, 
queue, etc. We use this notion to look at simple executions. Since verifying linearizability is 
EXSPSPACE-complete, it is important to seek for natural assumptions that concurrent imple¬ 
mentations satisfy. This kind or research can potentially lead to constructing feasible verification 
techniques. 

We proved that if SMAV is an sb-snapshot algorithm, then SNAV is correct iff all its simple 
executions are correct. Relaying on our theorem, we concluded that known verification tech¬ 
niques (for example [3]) can be applied on finite sb-snapshot implementations. Recall that when 
we say that an implementation is finite, we mean that it is finite only when simple execution 
are assumed. Thus, our result is crucial for applying verification techniques such as the one in 

m- 

We consider this paper as a starting point for varied further research, as it raises many ques¬ 
tions. Since verifying linearizability is decidable but not feasible, we suggest two approaches 
for overcoming this problem. First, we suggest to adapt assumptions on the algorithm verified 
to be correct. For example, in [23] the verification techniques use an assumption on the lin¬ 
earization points. However, this assumption exclude some known algorithms, for example the 
queue implementation in m- We defined the schedule-based property and we argue that this 
property is very natural to assume. Second, we suggest to look at unique objects. Here we 
focus on the well-known snapshot object and we hope that our results can lead to designing 
polynomial verification tools for snapshot implementations. 

We set three main directions for further research in view of our ideas and results 

• Finding conditions that resemble the properties in definition 13.11 for other objects and 
data structures. 

• Applying the notion of sb-algorithms on other objects, and finding a corresponding vari¬ 
ants of our simple executions. 
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Use our reduction to simple executions to design polynomial automatic verification of 
sb-snapshot implementations. Replicating this approach for other objects and data struc¬ 
tures. 
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